← Return to doc.sitecore.com

  Configuration file changes in Sitecore CMS and DMS 6.6.0 rev. 120918 compared to CMS and DMS 6.6.0 rev. 120622
Print this page (opens in new window) Print

This update requires you to make changes to the following files:

The clean config files for Sitecore CMS 6.6.0 and DMS 6.6.0 rev. 120918 can be downloaded using the following links:

Changes to the Web.config file

The following changes have been made to the Web.config file of Sitecore CMS 6.6.0 rev. 120918 (Initial Release) as compared to the Web.config file of Sitecore CMS 6.6.0 rev. 120622 (Technical Preview):

  1. In the <appSettings> section, add the following key:
    <add key="Lucene.Net.FSDirectory.class" value="Sitecore.Search.FSDirectory, Sitecore.Kernel" />
  2. In the <pipelines> section, add a new pipeline <resolveRenderingDatasource>, after the <getRenderingDatasource> pipeline:
    <!--  Allows developers to override the default logic for resolving the data source for renderings. -->
    <resolveRenderingDatasource>
    </resolveRenderingDatasource>
  3. In the <sitecore><retryer> section, update the comment to the section:
    <!-- RETRYER
         When enabled, the Retryer resends failed database requests a specified number of times.
         For example, this is useful if you configure a Sitecore instance to support hot failover for database calls.
         Default value: disabled="true"
    -->
    <retryer disabled="true" type="Sitecore.Data.DataProviders.Retryer, Sitecore.Kernel">
      <param desc="Number of tries">6</param>
      <param desc="Interval between tries">00:00:00.500</param>
      <param desc="Log each exception (should be used for debug only)">true</param>
    </retryer>
  4. In the <sitecore><databases><database id="web"> section, remove the NotificationProvider node. The section now looks like this in a default Sitecore installation:
    <!-- web -->
    <database id="web" singleInstance="true" type="Sitecore.Data.Database, Sitecore.Kernel">
      <param desc="name">$(id)</param>
      <icon>Network/16x16/earth.png</icon>
      <securityEnabled>true</securityEnabled>
      <dataProviders hint="list:AddDataProvider">
        <dataProvider ref="dataProviders/main" param1="$(id)">
          <disableGroup>publishing</disableGroup>
          <prefetch hint="raw:AddPrefetch">
            <sc.include file="/App_Config/Prefetch/Common.config" />
            <sc.include file="/App_Config/Prefetch/Web.config" />
          </prefetch>
        </dataProvider>
      </dataProviders>
      <proxiesEnabled>false</proxiesEnabled>
      <proxyDataProvider ref="proxyDataProviders/main" param1="$(id)" />
      <archives hint="raw:AddArchive">
        <archive name="archive" />
        <archive name="recyclebin" />
      </archives>
      <cacheSizes hint="setting">
        <data>20MB</data>
        <items>10MB</items>
        <paths>500KB</paths>
        <standardValues>500KB</standardValues>
      </cacheSizes>
    </database>
  5. In the comment above to <sites> section, the description of the dictionaryDomain attribute has been updated to look like this:
          dictionaryDomain: The default domain to use when looking up dictionary phrases for the website. If a phrase does not exist in
                            this dictionary domain, Sitecore attempts to locate that phrase in the default dictionary domain  -
                            /sitecore/system/Dictionary in the current database. If the phrase cannot be found in the default dictionary domain, Sitecore attempts to locate that phrase
                            in the default dictionary domain in the Core database, if that database exists.
                            You can override the site-specific dictionary domain by passing parameters to the Translate.Text() method.
  6. In the <sitecore><settings> section, change the comments for the three following settings related to the Page Preview feature:
    <!--  PAGE PREVIEW SITE NAME
          Specifies the name of the site that is used to generate page previews, for example "website".
          If blank, Sitecore uses the value in the Preview.DefaultSite setting.
          Default value: "" (use the value of the Preview.DefaultSite setting)
    -->
    <setting name="PagePreview.SiteName" value="" />
    <!--  PAGE PREVIEW SESSION EXPIRATION PERIOD
          Specifies the period of time during which page previews are valid.
          Default value: 365.00:00:00 (1 year)
    -->
    <setting name="PagePreview.SessionExpirationPeriod" value="365.00:00:00" />
    <!--  PAGE PREVIEW MAX PREVIEW SESSIONS COUNT
          Specifies the maximum number of preview sessions that are stored for a language version of an item.
          Default value: 32
    -->
    <setting name="PagePreview.MaxSessionsCount" value="32" />

Changes to the Sitecore.Analytics.config file

Notice: This file does not exist and does not need to be upgraded if you have not installed Sitecore Analytics.

Tip: Most customers have only applied a small number of changes (if any) to the Sitecore.Analytics.config file. In that case, we strongly recommend that you simply download the clean config file using the link above and re-apply any changes that you've made to save time and to reduce the risk of making mistakes when adding the new settings, pipelines, etc. to the file.

The following changes have been made to the Sitecore.Analytics.config file of DMS 6.6.0 rev. 120918 (Initial Release) as compared to the Sitecore.Analytics.config file of DMS 6.6.0 rev. 120622 (Technical Preview).

  1. The comments for almost all the settings in the file have been updated to make them more descriptive. We recommend that you download a clean version of the Sitecore.Analytics.config file and re-apply any changes that you've made (in which case you can skip step 2-7 below).
  2. In the <settings> section, add the following setting:
    <!--  ANALYTICS TRACKER CHANGES LONG OPERATION THRESHOLD
          Defines the threshold value in milliseconds for logging long running analytics tracker operations, such as analytics insert operations.
          Default: 2500 (2.5 seconds)
    -->
    <setting name="Analytics.TrackerChanges.LongOperationThreshold" value="2500" />
  3. The default value of the Analytics.Automation.BatchSize setting has been changed from 1000 to 10. Change the value of this setting from 1000 to 10 unless you have set it to a different value:
    <!--  ANALYTICS AUTOMATION BATCH SIZE
          Defines the number of records that should be processed in a batch.
          Default: 10
    -->
    <setting name="Analytics.Automation.BatchSize" value="10" />
  4. In the <settings> section, add the following setting:
    <!--  ANALYTICS AUTOMATION LOCK EXPIRATION
          When Sitecore processes automation states, the system marks the rows in the database that it is about to process. If
          the states are not successfully processed, the rows are processed again at a later time.
          This can happen, for example, if the server restarts while the rows are being processed.
          This setting specifies the minimum wait time (in seconds) before the rows can be selected for re-processing.
          Default: 3 (3 seconds)
    -->
    <setting name="Analytics.Automation.LockExpiration" value="3" />
  5. In the <automation> pipeline, remove the node of type LastAccessedDateTime. The <automation> pipeline now looks like this in a default Sitecore installation:
    <automation>
      <processor type="Sitecore.Analytics.Pipelines.Automation.GetAutomationStateItem,
    Sitecore.Automation.MarketingAutomation" />
      <processor type="Sitecore.Analytics.Pipelines.Automation.ProcessCommands,
    Sitecore.Automation.MarketingAutomation" />
      <processor type="Sitecore.Analytics.Pipelines.Automation.SetNextWakeUpTime,
    Sitecore.Automation.MarketingAutomation" />
    </automation>
  6. In the <acceptChanges> pipeline, move the DropCancelledPage processor to the very first position in the pipeline and add a new processor of type UpdateAutomationStates, between the GeneratingCampaignEvents and AcceptSharedChanges processors. The <acceptChanges> pipeline now looks like this in a default Sitecore installation:
    <acceptChanges>
      <processor type="Sitecore.Analytics.Pipelines.AcceptChanges.DropCancelledPage,Sitecore.Analytics"/>
      <processor type="Sitecore.Analytics.Pipelines.AcceptChanges.DoNotWrite,Sitecore.Analytics"/>
      <processor type="Sitecore.Analytics.Pipelines.AcceptChanges.Robots,Sitecore.Analytics"/>
      <processor type="Sitecore.Analytics.Pipelines.AcceptChanges.GeneratingCampaignEvents,
    Sitecore.Analytics"/>
      <processor type="Sitecore.Analytics.Pipelines.AcceptChanges.UpdateAutomationStates,
    Sitecore.Automation.MarketingAutomation"/>
      <processor type="Sitecore.Analytics.Pipelines.AcceptChanges.AcceptSharedChanges,
    Sitecore.Analytics"/>
      <processor type="Sitecore.Analytics.Pipelines.AcceptChanges.AcceptVisitorChanges,
    Sitecore.Analytics"/>
    </acceptChanges>
  7. In the <pipelines> section, add a new pipeline <excludeRobots>:
    <excludeRobots>
      <processor type="Sitecore.Analytics.Pipelines.ExcludeRobots.TryObtainCachedResult,
    Sitecore.Analytics"/>
      <processor type="Sitecore.Analytics.Pipelines.ExcludeRobots.CheckUserAgent,Sitecore.Analytics"/>
      <processor type="Sitecore.Analytics.Pipelines.ExcludeRobots.CheckIpAddress,Sitecore.Analytics"/>
      <processor type="Sitecore.Analytics.Pipelines.ExcludeRobots.AddResultToCache,Sitecore.Analytics"/>
    </excludeRobots>

Changes to the Commands.config file

The following changes have been made to the Commands.config file of Sitecore CMS 6.6.0 rev. 120918 (Initial Release) as compared to the Commands.config file of Sitecore CMS 6.6.0 rev. 120622 (Technical Preview):

  1. Add the following 3 commands (it is suggested to add them in alphabetical order in relation to the existing commands, but they can be added at any place):
    <command name="dashboard:opensinglecampaign" type="Sitecore.Shell.Framework.Commands.Dashboard.OpenSingleCampaign,Sitecore.Client" />
    <command name="item:archiveitem" type="Sitecore.Shell.Framework.Commands.Archive,Sitecore.Kernel" />
    <command name="item:archiveversion" type="Sitecore.Shell.Framework.Commands.ArchiveVersion,Sitecore.Kernel" />
  2. Remove the following 2 commands "item:archive" and "item:archivedateclear":
    <command name="item:archive" type="Sitecore.Shell.Framework.Commands.Archive,Sitecore.Kernel" />
    <command name="item:archivedateclear" type="Sitecore.Shell.Framework.Commands.ArchiveDateClear,Sitecore.Kernel" />

Changes to the Sitecore.Mvc.config.disabled file

Notice: If you have enabled Sitecore MVC, this file will be named Sitecore.Mvc.config.

Tip: Most customers have only applied a small number of changes (if any) to the Sitecore.Mvc.config.disabled file. In that case, we strongly recommend that you simply download the clean config file using the link above and re-apply any changes that you've made to save time and to reduce the risk of making mistakes when adding the new settings, pipelines, etc. to the file.

The following changes have been made to the Sitecore.Mvc.config.disabled file of Sitecore CMS 6.6.0 rev. 120918 (Initial Release) as compared to the Sitecore.Mvc.config.disabled file of Sitecore CMS 6.6.0 rev. 120622 (Technical Preview):

  1. The comments for almost all the settings in the file have been updated to make them more descriptive. We recommend that you download a clean version of the Sitecore.Mvc.config.disabled file and re-apply any changes that you've made (in which case you can skip step 2-4 below).
  2. In the <settings> section, add the following setting:
    <!--  MVC DECODE RENDERING PARAMETERS TWICE
          Flag to control whether or not rendering parameters should be decoded twice (Sitecore double-encodes them).
          Default value: true
    -->
    <setting name="Mvc.DecodeRenderingParametersTwice" value="true" />
  3. In the <mvc.exception> pipeline, which was previously empty, add a node for a processor of type ShowAspNetErrorMessage:
    <processor type="Sitecore.Mvc.Pipelines.MvcEvents.Exception.ShowAspNetErrorMessage, Sitecore.Mvc"/>
  4. In the <pipelines><mvc.getModel> section, remove processor GetFromModelField and add four new processors GetFromItem, GetFromProperty, GetFromLayout, GetFromRenderingItem:
    <mvc.getModel>
      <processor type="Sitecore.Mvc.Pipelines.Response.GetModel.GetFromItem, Sitecore.Mvc"/>
      <processor type="Sitecore.Mvc.Pipelines.Response.GetModel.GetFromProperty, Sitecore.Mvc"/>
      <processor type="Sitecore.Mvc.Pipelines.Response.GetModel.GetFromLayout, Sitecore.Mvc"/>
      <processor type="Sitecore.Mvc.Pipelines.Response.GetModel.GetFromRenderingItem, Sitecore.Mvc"/>
      <processor type="Sitecore.Mvc.Pipelines.Response.GetModel.CreateDefaultRenderingModel, Sitecore.Mvc"/>
      <processor type="Sitecore.Mvc.Pipelines.Response.GetModel.InitializeModel, Sitecore.Mvc"/>
    </mvc.getModel>

Changes to the Sitecore.MvcAnalytics.config.disabled file

Notice: If you have enabled Sitecore MVC, this file will be named Sitecore.MvcAnalytics.config.

Tip: Most customers have not made any changes to the Sitecore.MvcAnalytics.config.disabled file. In that case, we strongly recommend that you simply download the clean config file using the link above.

The following changes have been made to the Sitecore.MvcAnalytics.config.disabled file of Sitecore CMS 6.6.0 rev. 120918 (Initial Release) as compared to the Sitecore.MvcAnalytics.config.disabled file of Sitecore CMS 6.6.0 rev. 120622 (Technical Preview):

  1. In the <pipelines> section, remove the pipeline <mvc.actionExecuting> .
  2. In the <pipelines> section, add a new pipeline <mvc.requestBegin>:
    <mvc.requestBegin>
      <processor type="Sitecore.Mvc.Analytics.Pipelines.MvcEvents.RequestBegin.StartTracking, Sitecore.Mvc.Analytics"/>
    </mvc.requestBegin>